Amendments to the Specification: 

Please amend the paragraph beginning on line 22 of page 10 of the application to read as 
follows: 

As discussed in more detail below, the regional data centers 16 also deliver content 
to a user 20 if a standalone media serving system 14 is not available to that particular user 
20, or if that media serving system 14 does not include the content requested by the user 20. 
That is, the director at the encoding facility 28 preferably continuously monitors the status 
of the standalone media serving systems 14 and reroutes users 20 to the nearest regional 
data center 16 if the nearest media serving system 14 fails, reaches its fulfillment capacity 
or drops packets. Users 20 are typically assigned to the regional data center 14 that 
corresponds with the Internet backbone provider that serves their ISP, thereby maximizing 
performance of the second tier of the distribution network 12. The regional data centers ±4 
16 also serve any users 20 whose ISP does not have an edge server. 

Please amend the paragraph beginning on line 1 of page 1 1 of the application to read as 
follows: 

The master data centers 1 8 are similar to regional data centers 16, except that they 
are preferably much larger hardware deployments and are preferably located in a few 
peered data centers and co-location facilities, which provide the master data centers with 
connections to thousands of ISPs. Therefore, Fig. 3 is also used to illustrate an example of 
components included in a master data center 18. However, it is noted that a master data 
center 18 comprises multiterabyte storage networks (e.g., a larger number of media serving 
systems 14) to manage large libraries of content created, for example, by major media 
companies. As discussed in more detail below, the director at the encoding facility 28 
automatically routes traffic to the closest master data center 18 if a media serving system 14 
or regional data center 16 is unavailable to a user, or if the user has requested content that is 
not available at its designated media serving system 14 or regional data center 16. The 
master data centers 1 8 can therefore absorb massive surges in demand without impacting 
the basic operation and reliability of the network. 
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Please amend the paragraph beginning on line 14 of page 1 1 of the application to read as 
follows: 

The flow of data and content will now be discussed with reference to Figs. 4-8. As 
shown in Figs. 4 and 5 A-5D , the internet broadcast network 10 for streaming media 
generally comprises three phases, that is, acquisition 100 of Fig. 5A . broadcasting 102 of 
Fig. 5B, and receiving 104 of Figs. 5C and 5D . In the acquisition phase 100, content is 
provided to the network from different sources such as internet content providers (ICPs) or 
event or studio content sources 24, as shown in Fig. 1 . As stated previously, content can be 
received from audio and/or video equipment employed at a stadium for a live broadcast. 
The content can be, for example, live analog signals, live digital signals, analog tape 
recordings, digitally stored information (e.g., media-on-demand or MOD), among other 
types of content. The content can be locally encoded or transcoded at the source using, for 
example, file transport protocol (FTP), MSBD or real-time transport protocol/real-time 
streaming protocol (RTP/RTSP). 

Please amend the paragraph beginning on line 25 of page 1 1 through line 5 of page 12 of 
the application to read as follows: 

The content is collected using one or more acquisition modules 106 which are 
described in more detail below in connection with Fig. 6. The acquisition modules 106 
represent different feeds to the network 10 in the acquisition network 22 shown in Fig. 1, 
and the components of the acquisition modules 106 can be co-located or distributed 
throughout the acquisition network 28 22. Generally, acquisition modules 106 can perform 
remote transcoding or encoding of content using FTP, MSBD, or RTP/RTSP or other 
protocols prior to transmission to a broadcast module 1 10 for multicast to edge devices and 
subsequent rendering to users 20 of Fig. 1, located relatively near to one of the edge 
devices. The content is then converted into a broadcast packet in accordance with an 
embodiment of the present invention. This process of packaging packets in a manner to 
facilitate multicasting, and to provide insight at reception sites as to what the packets are 
and what media they represent, constitutes a significant advantage of the network 10 over 
other content delivery networks. 
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Please amend the paragraph beginning on line 6 of page 12 of the application to read as 
follows: 

Content obtained via the acquisition phase 100 is preferably provided to one or 
more broadcast modules 110 via a multicast cloud or network(s) 108. The content is unicast 
or preferably multicast from the different acquisition modules 106 to the broadcast modules 
1 10 via the cloud 108. As stated above, the cloud 108 is preferably a point-to-multipoint 
broadcast backbone. The cloud 108 can be implemented as one or more of a wireless 
network such as a satellite network or a terrestrial or wireline network such as optical fiber 
link. The cloud 108 can employ a dedicated ATM link or the internet backbone, as well as a 
satellite link, to multicast streaming media. The broadcast modules 1 10 are preferably in 
ti e r 120, that is, th e y ar e at the encoding center 28 that receive content from the acquisition 
modules 106 and, in turn, broadcast the content via satellite 32, ATM/Internet network 33, 
or both, to receivers at the media serving systems 14, regional data centers 16, and master 
data centers 18 (see Fig. 1) in tiers 116, 118 and 120, respectively (see Fig. 5 12). 

Please amend the paragraph beginning on line 19 of page 13 through line 7 of page 14 of 
the application to read as follows: 

Acquisition for plural customers A through X is illustrated in Fig. 6. By way of an 
example, acquisition for customer A involves an encoder, as indicated at 134, which can 
employ Real, WMT, MPEG, QT, among other encoding schemes with content from a 
source 24. The encoder also encodes packets into a format to facilitate broadcasting in 
accordance with the present invention. A disk 130 stores content from different sources 
and provides MOD streams, for example, to a disk host 132. The disk host 132 can be 
proxying the content or hosting it. Live content, teleconferencing, stock and weather data 
generating systems, and the like, on the other hand, is also encoded. The disk host 132 
unicasts the MOD streams to a file transport module 136, whereas the encoder 134 provides 
the live streams to a transport sender 138 via unicast or multicast. The encoder can employ 
either unicast or multicast if QT is used. Conversion from unicast to multicast is not always 
needed, but multicast to - multicast unicast-to-multicast conversion can be useful. The file 
transport module 136 transfers MOD content to a multicast-enabled network. The transport 
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sender 138 pulls stream data from a media encoder 134 or an optional aggregator and sends 
stream announcements (e.g., using session announcement protocol and session description 
protocol (SAP/SDP)) and stream data to multicast internet protocol (IP) addresses and ports 
received from a transport manager, such as 170 of Fig. 9, which is described in more detail 
below with reference to Fig. 9. When a Real G2 server is used to push a stream, as opposed 
to a pulling scheme, an aggregator can be used to convert from a push scheme to a pull 
scheme. The components described in connection with Fig. 6 can be deployed at the 
encoding center 28 or in a distributed manner at, for example, content provider facilities. 

Please amend the paragraph beginning on line 8 of page 14 of the application to read as 
follows: 

Fig. S 7 illustrates an exemplary footprint for one of a plurality of broadcasts. As 
shown in Fig. 5 7, the broadcasting phase 102 is implemented using a transport broadcaster 
140 and a transport bridge 142. These two modules are preferably implemented as one 
software program, but different functions, at a master data center 18 or network operations 
center. The transport broadcaster 140 performs transport path management, whereas the 
transport bridge 142 provides for peering. The broadcaster 140 and bridge 142 get data 
from the multicast cloud (e.g., network 108) being guided by the transport manager and 
forward it to an appropriate transport path. One transport broadcaster 140, for example, can 
be used to represent one transport path such as satellite uplink or fiber between data centers 
or even a cross-continental link to a data center in Asia from a data center in North 
America. The broadcaster 140 and bridge 142 listen to stream announcements from 
transport senders 138 of Fig. 6, and enable and disable multicast traffic to another transport 
path, accordingly. They can also tunnel multicast traffic by using TCP to send stream 
information and data to another multicast-enabled network. Thus, broadcast modules 110 
transmit corresponding subsets of the acquisition phase streams that are sent via the 
multicast cloud 108. In other words, the broadcast modules 110 operate as gatekeepers for 
their respective transport paths, that is, they pass any streams that need to be sent via their 
corresponding path and prevent passage of other streams. 
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Please amend the paragraph beginning on line 26 of page 14 through line 6 of page 15 of 
the application to read as follows: 

As stated above, Fig. 8 illustrates an example the reception phase 104 at one of a 
plurality of servers or data centers. As stated above, the data centers are preferably 
deployed in a tiered hierarchy comprising media serving systems 14, regional data centers 
16 a and master data centers 18 each of Fig. 1 . The tiers 116, 118 and 120 each of Fig. 12, 
comprise a transport receiver 144. Transport receivers can be grouped using, for example, 
the transport manager 170 of Fig. 9 . Each transport receiver 144 receives those streams 
from the broadcast modules 110 that are being sent to a group to which the receiver 
belongs. The transport receiver listens to stream announcements, receives stream data from 
plural transport senders 138 of Fig. 6, and feeds the stream data to media servers 146. The 
transport receiver 144 can also switch streams, as indicated at 154 (e.g., to replace a live 
stream with a local MOD feed for advertisement insertion purposes). The MOD streams are 
received via the file transport 136 of Fig. 6, and stored, as indicated via the disk host 148, 
database 150 and proxy cache/HTTP server 152. The servers 146 and 152 can provide 
content streams to users 20. 

Please amend the paragraph beginning on line 13 of page 15 of the application to read as 
follows: 

The transport manager 170 will now be described with reference to Fig. 9 which 
illustrates an overview of transport data management. The transport manager is preferably a 
software module deployed at the encoding facility 28 or other facility designated as a NOC. 
Multiple content sources 24 (e.g., database content, programs and applications) provide 
content as input into the transport manager 170. Information regarding the content from 
these data sources is also provided to the transport manager such as identification of input 
content source 24 and output destination (e.g., groups of receivers). Decisions as to where 
content streams are to be sent and which groups of servers (e.g., tiers 116, 1 18 or 120) are 
to receive the streams can be predefined and indicated to the transport manager 170 as a 
configuration file or XBM function call in real-time, for example, under control of the 
director as discussed in more detail below. This information can also be entered via a 
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graphical user interface (GUI) 172 or command line utility. In any event, the information is 
stored in a local database 174. The database 174 also stores information for respective 
streams relating to defined maximum and minimum DP address and port ranges, bandwidth 
usage, groups or communities intended to receive the streams, network and stream names, 
as well as information for user authentication to protect against unauthorized use of streams 
or other distributed data. 

Please amend the paragraph beginning on line 15 of page 16 of the application to read as 
follows: 

As discussed above a an and in more detail below, once the transport sender 138 
commences sending the stream into the assigned multicast IP address and port, the transport 
broadcaster 140 of the corresponding broadcast module 110 (see Fig. 7) will filter the 
stream. The transport receiver 144 of the appropriate tier or tiers 1 16, 1 18 or 120 (see Fig. 
8) joins the multicast IP address and receives the data or stream if the stream is intended for 
a group to which the receiver 144 belongs. As stated above in connection with Fig. 8, the 
transport receiver 144 converts the steam received via the cloud 108 and sends it to the 
media server available to the users 20. The data is then provided to the media server 
associated with the receiver. Receivers 144 and broadcasters 140 track announcements that 
they have honored using link lists. 

Please amend the paragraph beginning on line 25 of page 16 of the application to read as 
follows: 

As stated above, the transport components preferably use RPT RTP as a data 
transport protocol. Accordingly, Windows Media, RealG2 and QT packets are wrapped 
into RTP packets. The acquisition network 22 ofFig. K preferably employs an RTP stack to 
facilitate processing any data packets, wrapping the data packets with RTP header and 
sending the data packets. RTSP connection information is generally all that is needed to 
commence streaming. 
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Please amend the paragraph beginning on line 16 of page 18 of the application to read as 
follows: 

As discussed above, the master data centers 18 are configured to support enormous 
numbers of requests for streaming media and thus, is the first tier 120 of redundancy for 
handling requests by end users from the Internet in general. The regional data centers 16 
make up the second tier 118 and are strategically disposed at major "backbone" points 
across the Internet. The regional data centers 16 service traffic from within one subnetwork 
on the Internet to use within the same subnetwork, thus preventing the content of the data 
from being subjected to problems and idiosyncrasies associated with private and public 
peering which can occur on the Internet as can be appreciated by one skilled in the art. The 
regional data centers 16 are also capable of serving high volumes of data streams. The 
media serving systems 14, which make up the third tier 1 16 of the network WO 12, are 
disposed within the access providers' points of presence (POPs) which are generally less 
than two router hops away from the end user. These media serving systems 14 are generally 
not subject to any of the idiosyncrasies of the Internet, and thus can be scaled to meet the 
needs of the specific POP. 

Please amend the paragraph beginning on line 30 of page 18 through line 4 of page 19 of 
the application to read as follows: 

The master data centers 18, in conjunction with the encoding facility 28, includ e a 
includes the a director 200, which includes a distributed server application. The director 
200 can poll information about the network 10 from a plurality of sources in the network 10 
from other directors present at the regional data centers 16 and media serving systems 14, 
and can use this information to determine or modify the positions in the streaming data at 
which data received from content providers should be placed, so as to best distribute that 
data to the regional data centers 16 and media serving systems 14. 
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Please amend the paragraph beginning on line 5 of page 19 of the application to read as 
follows: 

Referring to Fig. 1, under control of the director 200 of Fig. 10 , the encoder 28 
uplinks data received from content providers to the master data center or centers 1 8 5 the 
regional data servers 16 and the media serving systems 14 via satellite 32, ATM/Internet 
network 33, or both. The components of the network 10 cooperate as discussed above to 
insure that the correct multicast stream reaches every server in the network 10. Also, the 
satellite delivery of the data leverages the economy of scale realizable through known 
broadcast technology, and further, bypasses the slower and costlier terrestrial backbone of 
the Internet to provide the end user with consistent and faster Internet performance, which 
results in lower bandwidth costs, better quality of service, and offer new opportunities. The 
package delivery software employed at the encoding facility allows the data files to be 
distributed by multicast UDP/IP, TCP/IP, or both, as can be appreciated by one skilled in 
the art. Also, the package delivery software includes a queuing server as well as a 
retransmission server that cooperate to transmit the data and quickly recover any lost data 
packets. This recovery scheme results in smoother delivery of streaming audio, video and 
multimedia data to the Internet. 

Please amend the paragraph beginning on line 19 of page 19 of the application to read as 
follows: 

The encoding facility 28 distributes content to tiers 1 16, 1 18 and 120 to insure that 
the data from the content providers are efficiently and cost-effectively multicast out to all 
three tiers of the network 10 simultaneously. As shown in Fig. 10, the director constantly 
monitors the network and adapts to changes, ensuring the quality of applications run on the 
network 10. As further shown, relay software 202 is distributed throughout the network 10 
to provide a reliable transport layer that makes sure no packets get lost across the broadcast 
backbone. The transport layer also lets applications scale connections from one-to-few to 
one-to-many. In addition to receiving and unpacking data from the broadcast backbone, the 
relay software 202 manages local storage and reports to the director 200 on the status of the 
remote server and its applications. 
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Please amend the paragraph beginning on line 15 of page 21 of the application to read as 
follows: 

As further shown, a remote or edge server in the network 12, such as a media 
serving system 14, can receive the encoded and/or unencoded content at a receiver 192. The 
media serving system 14 can include an encoder 194 for encoding, for example, the 
unencoded content provided from receiver 192. Accordingly, a non-compressed file can be 
sent to edge devices that provide IP connectivity (e.g., media serving centers 14) in the 
network 10 and compressed there, as opposed to at the encoding center 28. This method 
uses bandwidth more efficiently by obviating the need to transmit both non-compressed and 
compressed versions of a file, in In addition, only the compressed version of a file can be 
sent and then uncompressed at the edge devices. 

Please amend the paragraph beginning on line 23 of page 23 of the application to read as 
follows: 

One problem with media servers is that the tools for determining current server 
performance are minimal, at best. Hence, in a distributed network such as network 10, it is 
crucial that the exact state of each server is known on a continued basis, so that the director 
can make the correct decisions if the server should receive additional requests. The director 
therefore has specific tools and utilities to assess the current state of any server, as well as 
the number of current streams being served and the bandwidth of those streams. These tools 
report back current server state information that the director evaluates when determining the 
best server from which data should be provided in response to a particular user request. 

Example of scenarios in which the director will determine from which server a data 

request should be handled for a particular user will now be described with reference to Fig. 
11. 
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